A continuation based runtime typically executes activities or programs. An activity typically represents a unit of executable code consisting of multiple pulses of work. One manner in which an activity can execute multiple pulses of work is through the scheduling of child activities. Such a composition of activities typically enables custom control flows that can be implemented through the scheduling of child activities zero or more times as determined by the composite activity. An activity can also setup a resumable continuation or bookmark in its execution that is resumed by a stimulus external to the runtime. The runtime interprets this external stimulus as another pulse of work to be handled by the activity. Pulses of work are typically represented as continuations that the runtime invokes on activities (thus, continuation based runtime). Beyond the flexibility to create new control flows and handle external resumptions, activities generally include the following characteristics: they have no process affinity—they can be paused and resumed in a different process; they have no thread affinity—different pulses of work can run on different threads; they can be persisted and rehydrated.
Dealing with external stimuli can present several complications. For example, multiple stimuli can occur simultaneously. In general, a continuation based runtime processes stimuli as they arrive. A continuation based runtime should be capable of predictably managing multiple external stimuli relative to internal state. Such management is typically performed by assessing validity of the stimulus either for immediate processing or by determining that the activity will never enter a state wherein the stimulus is valid. Such management typically results in a program's ability to accept or reject a stimulus. But it may be desirable to further determine if the stimulus may be valid for processing at a later point in the activity.